fix usage-limit cooldown persistence - #354

This is a comment left during a code review.
Path: test/fetch-helpers.test.ts
Line: 1181-1188

Comment:
**test indented at wrong describe scope**

this test was migrated from the old top-level `it('caps retryAfterMs at 5 minutes'` but its indentation (1 tab) was not updated to match the surrounding nested group (3 tabs, lines 1147–1179 and 1190+). it still runs and passes, but it is not inside the same `describe` block as the other cap tests, so grouping and scoping are inconsistent.

```suggestion
			it('caps retryAfterMs at 7 days', async () => {
				const body = { error: { message: 'rate limited', retry_after_ms: 10 * 24 * 60 * 60 * 1000 } };
				const response = new Response(JSON.stringify(body), { status: 429 });
				
				const { rateLimit } = await handleErrorResponse(response);
				
				expect(rateLimit?.retryAfterMs).toBe(7 * 24 * 60 * 60 * 1000);
			});
```

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: lib/preemptive-quota-scheduler.ts
Line: 221-228

Comment:
**secondary slot usedPercent silently dropped on markRateLimited**

`secondary: {}` wipes any existing `secondary.usedPercent` from a prior `update()` call. the secondary reset timestamp is correctly folded into `nextResetAtMs` on the primary slot, so deferral is preserved during the active 429 window. however, once the cooldown expires and the snapshot is pruned, the near-exhaustion signal on the secondary quota is gone until the next successful response restores it via `update()`. this is benign in the common path but worth noting for observability: a request that lands between cooldown expiry and the next successful header could skip the `quota-near-exhaustion` deferral branch.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: index.ts
Line: 2148-2150

Comment:
**original fallback response body stream not cancelled**

the old code explicitly called `fallbackResponse.body?.cancel()` (best-effort cleanup) before moving to the next account. the replacement `handleErrorResponse(fallbackResponse)` calls `safeReadBody` via `response.clone().text()`, which consumes the *clone's* body but leaves the original undici stream open. on long-lived http/2 connections this can delay socket reuse until gc. adding an explicit cancel after the read would restore the original safety net:

```typescript
const { response: handledFallbackResponse, rateLimit: fallbackRateLimit } =
    await handleErrorResponse(fallbackResponse);
try { await fallbackResponse.body?.cancel(); } catch { /* best effort */ }
```

How can I resolve this? If you propose a fix, please make it concise.